WIP integration test for reactor make options. This may not be a very efficient or robust way to test behaviour. The "resume from" (-rf) option is not yet tested.

@joeshannon we can always improve extend it and an test not covering all cases is better than no test at all, lets see what the CI build do with it :-)

Unit Test Results

146 files  146 suites   40m 11s ⏱️
240 tests 237 ✔️ 3 💤 0 ❌

Results for commit 870cbbb.

♻️ This comment has been updated with latest results.

@joeshannon many thanks for this useful examples! I have noticed that I need to specify -Dtycho.localArtifacts=ignore if I once installed the artifacts successfully once is this something you also see and would expect?

e.g. this runs sucessful

mvn clean install -Dtycho-version=2.7.0-SNAPSHOT
mvn clean install -Dtycho-version=2.7.0-SNAPSHOT -am -pl feature1

ignoring already build artifacts fails:

mvn clean install -Dtycho-version=2.7.0-SNAPSHOT -am -pl feature1 -Dtycho.localArtifacts=ignore

@laeubi Yes I believe that is correct - if the artifact is available in a repository, that version will be used to build specified reactor projects if it's not otherwise included in the reactor.

I've been testing these use cases with a plain maven build with pom dependencies.

/rebase

Hm, isn't this missing the .mvn/extensions.xml file?

Also, I cannot get things to work as expected.

E.g., building

mvn clean verify -Dtycho-version=2.7.0-SNAPSHOT -am -pl feature1 -debug -Dtycho.debug.resolver

I'd expect only bundle1 and feature1 to be part of the build.

However, the result is this:

[INFO] Reactor Summary for parent 1.0.0-SNAPSHOT:
[INFO]
[INFO] parent ............................................. SUCCESS [  0.112 s]
[INFO] bundle1 ............................................ SUCCESS [  1.170 s]
[INFO] bundle2 ............................................ SUCCESS [  0.162 s]
[INFO] feature1 ........................................... SUCCESS [  0.062 s]
[INFO] feature2 ........................................... SUCCESS [  0.052 s]
[INFO] ------------------------------------------------------------------------

Debug log shows:

[DEBUG] TychoGraphBuilder:
[DEBUG]   - SelectedProjects: [feature1]
[DEBUG]   - ExcludedProjects: []
[DEBUG]   - MakeBehavior:     make-upstream
[DEBUG] Resolve dependencies for project feature2...

So far so good. But later:

[DEBUG] Computing additional make-upstream dependencies based on initial project set of parent, feature1
[DEBUG]  + add upstream project 'feature2' of project 'feature1'...
[DEBUG]  + add downstream project 'bundle1' of project 'feature2'...
[DEBUG]  + add downstream project 'bundle2' of project 'feature2'...
[DEBUG]  + add downstream project 'feature1' of project 'feature2'...
[DEBUG]  + add downstream project 'bundle1' of project 'bundle2'...

• Why is parent suddenly part of the requested projects?
• feature2 is not an upstream of feature1, this is strange.

Hm, isn't this missing the .mvn/extensions.xml file?

correct, do you like to add one?

• Why is parent suddenly part of the requested projects?

The initial project set is that set of project that the default maven would have computed to be build upon your request.

• feature2 is not an upstream of feature1, this is strange.

Probably because I do not got it correct how it is supposed to work. As feature 2 requires feature1 I assumed it is an upstream candidate?

In any case you can provide the build with -Dtycho.debug.resolver=true to see detailed output what dependencies where computed between the projects.

Hm, isn't this missing the .mvn/extensions.xml file?

correct, do you like to add one?

I cannot modify this PR, @joeshannon could you add one?

• Why is parent suddenly part of the requested projects?

The initial project set is that set of project that the default maven would have computed to be build upon your request.

But since parent contains everything else als modules, wouldn't that mean it also depends on everything else? That way we would end up with everything.

• feature2 is not an upstream of feature1, this is strange.

Probably because I do not got it correct how it is supposed to work. As feature 2 requires feature1 I assumed it is an upstream candidate?

feature2 is a downstream candidate of feature1.

In any case you can provide the build with -Dtycho.debug.resolver=true to see detailed output what dependencies where computed between the projects.

Sure, see attachment log.log

But since parent contains everything else als modules, wouldn't that mean it also depends on everything else? That way we would end up with everything.

Tycho doesn't care about modules, and as this the parent is "just there"

If you do not specify -X its a bit more convient to read, anyways here is the summary:

[DEBUG] [[ project feature2 depends on: ]]
[DEBUG]  IU: bundle1 1.0.0.qualifier [of project bundle1]
[DEBUG]  IU: bundle2 1.0.0.qualifier [of project bundle2]
[DEBUG]  IU: feature1.feature.group 1.0.0.qualifier [of project feature1]
[DEBUG] [[ project feature1 depends on: ]]
[DEBUG]  IU: bundle1 1.0.0.qualifier [of project bundle1]
[DEBUG] [[ project bundle2 depends on: ]]
[DEBUG]  IU: bundle1 1.0.0.qualifier [of project bundle1]

So we add feature2 as it is an upstream of feature1, the rest are added because feature1 or feature2 requires them, is this incorrect?

Ah, yes.

I think upstream/downstream are switched in the current implementation.

-am X / --also-make X == build X and everything X depends on == build X and upstream of X
-amd X / --also-make-dependents X == build X and everything that depends on X == build X and downstream of X

So if(projectRequest.requestUpstream) and if(projectRequest.requestDownstream) need to be switched.

Thank you for the discussion and hints.

In the initial revision I had accidentally made a dependency from bundle2 -> bundle1 which confused me for a while.

I think the behaviour is as expected now but might need a little more thought to confirm (btw if you would like to see the simple pure maven project I was using to test the options against, I can provide that).

I have changed the "child" ProjectRequests to not use any upstream or downstream options themselves i.e.:

new ProjectRequest(project, false, false, projectRequest)

I think this is correct since the streams/iterations over projectDependenciesMap look as though they are giving us all the direct/indirect dependencies in both directions but let me know if this seems wrong.

The only other thing that concerned me is that these tests do take a while to run (~80s on my machine) due to maven being invoked many times, is this acceptable for the its? Also the failure message strings are potentially brittle and could be broken by string formatting changes - I wasn't really sure of a better way to test this.

Thanks for looking into this. Actually the integration-tests are the real 'source-of-truth' and are thus of high value for keeping all the stuff working so we generally don't mind the runtime but are working on make them execute more in parallel so don't mind here.

So as tests are fine and we have not (yet) any complains I'll merge this, if any issue arise we can extend the test and code in further steps!

I have changed the "child" ProjectRequests to not use any upstream or downstream options themselves i.e.:

new ProjectRequest(project, false, false, projectRequest)

I think this is correct since the streams/iterations over projectDependenciesMap look as though they are giving us all the direct/indirect dependencies in both directions but let me know if this seems wrong.

Interesting.

Maybe we should have an integration test that tests that over more than one layer?
E.g. add a bundle3 depending on bundle2.
Or -pl feature2 and expect that everything is selected.

what do you think?

what do you think?

More tests are always better :-)

By the way, there is also some room for improvements if only dependent projects are requested one do only need to resolve the dependencies for those (currently all projects are calculated for dependencies) if we do not need to add dependent-of-dependecies.

ok as though they are giving us all the direct/indirect dependencies

Actually it should give all dependencies but as mentioned earlier, this is currently a bit experimental as we do allow incomplete resolving and e.g. do not take the target platform into account. But given that the reactor project set is rather well-defined also without the target (what should be the case in most scenarios) I don't see a problem.

I just wonder for the "build what depends on" case, e.g. I have feature1 depends on feature2, now I request feature2+everything that depends on it, I need to add everything feature1 depends to get a full set as feature2 will only add feature1 thats why I added all transistive dependencies of all extra selected projects.

Correct. In the current state the following currently fails using this set of integration test projects:

-amd -pl bundle1

because it picks up feature1, then picks up feature2, but feature2 itself depends on bundle2, but this is not selected.

I propose to add the flag back. Otherwise the -amd flag would be of little practical use.

@sratz can you add a bug (targeted at 2.7.0) and extend the integration test for this purpose?
Maybe we should simply use the flag this if -amd is specified and not for -am?

@sratz can you add a bug (targeted at 2.7.0) and extend the integration test for this purpose? Maybe we should simply use the flag this if -amd is specified and not for -am?

Done: #608